fix(dependency): Issue with jackson-bom and kotlin-bom version conflict resolution while upgrading the spring-boot 2.3.x #1505
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Spring boot has moved to gradle based dependency management from v2.3.x. This change has brought issue of conflict resolution failure of the Jackson-bom version and kotlin-bom version with gate service when it consumes the maven-bom generated by kork. The issue details are available in given link. https://docs.google.com/document/d/1Ck4KeoB1ER0aQUTnf3e-x-M3i2Ur0It7YaaxEMiMXls/edit To resolve this issue while upgrading gate service with spring v2.3.x, we must require the spring dependency management gradle plugin.
|
@Mergifyio update |
✅ Branch has been successfully updated |
|
It's tempting to put this in https://github.com/spinnaker/spinnaker-gradle-project which applies plugins on behalf of "all the projects"...but I believe those plugins are built-in to gradle, and so don't have a version to manage like I am hoping to manage the version bumping via bumpdeps, and perhaps tackle the version bumping of |
j-sandy
changed the title
j-sandy
changed the title
|
Explored an alternative approach to fix this issue. |
…dle plugin" This reverts commit b3b2c9e.
…ct resolution while upgrading the spring-boot 2.3.x. The root cause of this issue is uncontrolled conflict resolution of jackson-bom and kotlin-bom dependency version imported from external maven BOM provided by kork-bom, as per the gradle documentation https://docs.gradle.org/6.9.1/userguide/platforms.html#sub:bom_import, we can use gradle enforcedPlatform closure as part of the implementation to strictly adhere the versions of direct and transitive dependencies imported BOM. implementation(enforcedPlatform("io.spinnaker.kork:kork-bom:$korkVersion"))
j-sandy
force-pushed
the
sb-gradle-plugin
branch
from
8643f1b to
1d8f8b6
Compare
|
Before applying enforcedPlatform fix: After applying enforcedPlatform fix: |
|
Before applying enforcedPlatform fix: After applying enforcedPlatform fix: |
dbyron-sf
approved these changes
Feb 28, 2022
j-sandy
added a commit
to j-sandy/clouddriver
that referenced
this pull request
Mar 4, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
j-sandy
added a commit
to j-sandy/orca
that referenced
this pull request
Mar 4, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
j-sandy
added a commit
to j-sandy/rosco
that referenced
this pull request
Mar 7, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
j-sandy
added a commit
to j-sandy/halyard
that referenced
this pull request
Mar 8, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
j-sandy
added a commit
to j-sandy/echo
that referenced
this pull request
Mar 8, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
j-sandy
added a commit
to j-sandy/igor
that referenced
this pull request
Mar 10, 2022
…ct resolution while upgrading the spring-boot 2.3.x The root cause of this issue is uncontrolled conflict resolution of jackson-bom and kotlin-bom dependency version imported from external maven BOM provided by kork-bom, as per the gradle documentation here (https://docs.gradle.org/6.9.1/userguide/platforms.html#sub:bom_import), we can use gradle enforcedPlatform closure as part of the implementation to strictly adhere the versions of direct and transitive dependencies imported BOM. This approach could be considered as optimally feasible fix for this issue. And for upcoming upgrades and developments, it will also ensure the predictable dependency imports from kork-bom. Similar issue has been encountered while upgrading spring-boot to 2.3.x for gate service, for detailed discussion please refer to: spinnaker/gate#1505 This fix is seamless for the existing code.
j-sandy
added a commit
to j-sandy/front50
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
mergify bot
pushed a commit
to spinnaker/front50
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#1104) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
mergify bot
pushed a commit
to spinnaker/echo
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#1158) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
mergify bot
pushed a commit
to spinnaker/fiat
that referenced
this pull request
Mar 10, 2022
…ct resolution while upgrading the spring-boot 2.3.x (#923) The root cause of this issue is uncontrolled conflict resolution of jackson-bom and kotlin-bom dependency version imported from external maven BOM provided by kork-bom, as per the gradle documentation here (https://docs.gradle.org/6.9.1/userguide/platforms.html#sub:bom_import), we can use gradle enforcedPlatform closure as part of the implementation to strictly adhere the versions of direct and transitive dependencies imported BOM. This approach could be considered as optimally feasible fix for this issue. And for upcoming upgrades and developments, it will also ensure the predictable dependency imports from kork-bom. Similar issue has been encountered while upgrading spring-boot to 2.3.x for gate service, for detailed discussion please refer to: spinnaker/gate#1505 This fix is seamless for the existing code.
mergify bot
pushed a commit
to spinnaker/halyard
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#1936) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
mergify bot
pushed a commit
to spinnaker/igor
that referenced
this pull request
Mar 10, 2022
…ct resolution while upgrading the spring-boot 2.3.x (#997) The root cause of this issue is uncontrolled conflict resolution of jackson-bom and kotlin-bom dependency version imported from external maven BOM provided by kork-bom, as per the gradle documentation here (https://docs.gradle.org/6.9.1/userguide/platforms.html#sub:bom_import), we can use gradle enforcedPlatform closure as part of the implementation to strictly adhere the versions of direct and transitive dependencies imported BOM. This approach could be considered as optimally feasible fix for this issue. And for upcoming upgrades and developments, it will also ensure the predictable dependency imports from kork-bom. Similar issue has been encountered while upgrading spring-boot to 2.3.x for gate service, for detailed discussion please refer to: spinnaker/gate#1505 This fix is seamless for the existing code.
mergify bot
pushed a commit
to spinnaker/orca
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#4231) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
mergify bot
added a commit
to spinnaker/rosco
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#854) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
mergify bot
added a commit
to spinnaker/clouddriver
that referenced
this pull request
Mar 10, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#5652) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
11 tasks
6 tasks
rsh09
pushed a commit
to OpsMx/gate
that referenced
this pull request
Mar 31, 2022
* fix(oauth): remove circular dependency on ExternalAuthTokenFilter bean in OAuth2SsoConfig when oauth2 is enabled (spinnaker#1492) Previously in spring 2.2.5, if oauth2 is enabled there is no circular dependency on ExternalAuthTokenFilter bean in OAuth2SsoConfig. In spring 2.2.13, if oauth2 is enabled there is a circular dependency error on ExternalAuthTokenFilter bean. This circular dependency results in an error when the gate application tries to start up. The application fails with error: BeanCurrentlyInCreationException: Error creating bean with name 'OAuth2SsoConfig': Bean with name 'OAuth2SsoConfig' has been injected into other beans [externalAuthTokenFilter] in its raw version as part of a circular reference, but has eventually been wrapped. To fix this error, add the Component annotation to ExternalAuthTokenFilter and remove the ExternalAuthTokenFilter bean from OAuth2SsoConfig. Co-authored-by: David Byron <dbyron@salesforce.com> * fix(web): disable keel by default as it is an optional service (spinnaker#1453) Co-authored-by: Justin Field <justin.field@armory.io> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * fix(api): fix movie quotes to match movie script (spinnaker#1423) Co-authored-by: Justin Field <justin.field@armory.io> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * chore(build): gradle 6.8.1 (spinnaker#1413) Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * chore(dependencies): Autobump korkVersion (spinnaker#1493) Co-authored-by: root <root@265713e22300> * chore(dependencies): Autobump korkVersion (spinnaker#1495) Co-authored-by: root <root@ca7e6659c3b3> * chore(dependencies): Autobump korkVersion (spinnaker#1496) Co-authored-by: root <root@7e927306ac3d> * fix(vulnerability): avoid expose gate endpoints (spinnaker#1497) * chore(dependencies): Autobump korkVersion (spinnaker#1501) Co-authored-by: root <root@01b270ba5f94> * chore(dependencies): Autobump fiatVersion (spinnaker#1504) Co-authored-by: root <root@73790eeb50df> * chore(dependencies): Autobump korkVersion (spinnaker#1502) Co-authored-by: root <root@a229fbda21b3> Co-authored-by: Matt <6519811+mattgogerly@users.noreply.github.com> * feat(web): Expose experimental account storage API (spinnaker#1494) * feat(web): Expose experimental account storage API This adds some of the REST APIs introduced in the experimental account storage API in Clouddriver to Gate. Initially, these APIs are only available for admins. * Combine account and credentials endpoints * Add docs on AccountDefinition * Add alpha annotations * chore(build): update mergify config (spinnaker#1506) Co-authored-by: Cameron Motevasselani <cameron@armory.io> * fix(gate): Typos in Account Management API (spinnaker#1510) * fix(gate/web): Fix typo in PreAuthorize annotation It appears that some variables were renamed while I worked on the PR and didn't update the annotations to match. * fix(gate/core): Fix retrofit signature error * fix(gate/web): Add explicit name property to AccountDefinition (spinnaker#1514) This fixes an authorization check error where Jackson knows how to handle the `name` property of an account definition, but SpEL does not see the property. Now the PostFilter annotation should work equivalently to the same filter check in Clouddriver. * chore(dependencies): Autobump korkVersion (spinnaker#1515) Co-authored-by: root <root@d38215f0a8da> * fix(authn/oauth2): prevent oauth2 redirect loops (spinnaker#1517) During setup of spinnaker authentication with oauth2 a common hurdle is a redirect loop. For example: spinnaker/spinnaker#5794 spinnaker/spinnaker#1630 Also, many threads in Slack discuss these problems. In fact this appears to be a common pitfall for the spring-security-oauth2-autoconfigure library in general. A light refresher on the ouath2 flow in play here seems worthwhile. The user is redirected from `/login` in gate to the external auth provider (google, github, etc.) and after successfully authenticating they are redirected back to the gate `/login` endpoint but this time with a code parameter that is to be used to request an access token. This request can fail for a variety of reasons, and if it does, the underlying spring library triggers a redirect to the `/error` endpoint. What causes the redirect loop for gate in particular (and for other users of the library in a similar fashion) is that the WebSecurityConfigurerAdapter in play is treating `/error` as an authenticated path and so instead of just returning with a 401, it re-redirects to `/login` and the redirect loop continues. My thought is that instead of a redirect loop, simply allowing the 401 to be returned will be a stronger more helpful signal as to what is going on. Hopefully it will save future first-time installers headaches. Spinnaker docs have included several troubleshooting hints and tips for how where you terminate SSL affects configuration etc. Even after following all of these and lots of spelunking through spinnaker github issues and combing over threads in slack, I found myself still experiencing a redirect loop even though I had applied all the combined wisdom that was applicable to my setup. As it turns out, I had a bad copy/paste of my client secret in my configuration. So the request to turn the code from google into an access token from google was failing with a 401. After much debugging and deep diving into the spring security code I found that had I turned on DEBUG in gate for these classes in gate-local.yml: ``` logging: level: org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler: DEBUG org.springframework.security.oauth2.client.filter.OAuth2ClientAuthenticationProcessingFilter: DEBUG ``` Then I would have seen in the logs that a 401 response was returned from google and perhaps it would have caused me to look closer at my botched client secret configuration. I think perhaps we don't want to require that all operators of spinnaker become spring-security-oauth2 experts. So I'm proposing adding `/error` to the list of paths in gate that aren't treated as authenticated. Thus short-circuiting the redirect loop and bringing to light helpful troubleshooting info that was previously more or less swallowed. * chore(ci): update setup-java GHA to v2 (spinnaker#1518) closes: spinnaker/spinnaker#6611 * fix(dependency): Issue with jackson-bom and kotlin-bom version conflict resolution while upgrading the spring-boot 2.3.x (spinnaker#1505) * fix(dependency): Introducing spring dependency management gradle plugin Spring boot has moved to gradle based dependency management from v2.3.x. This change has brought issue of conflict resolution failure of the Jackson-bom version and kotlin-bom version with gate service when it consumes the maven-bom generated by kork. The issue details are available in given link. https://docs.google.com/document/d/1Ck4KeoB1ER0aQUTnf3e-x-M3i2Ur0It7YaaxEMiMXls/edit To resolve this issue while upgrading gate service with spring v2.3.x, we must require the spring dependency management gradle plugin. * Revert "fix(dependency): Introducing spring dependency management gradle plugin" This reverts commit b3b2c9e. * fix(dependency): Issue with jackson-bom and kotlin-bom version conflict resolution while upgrading the spring-boot 2.3.x. The root cause of this issue is uncontrolled conflict resolution of jackson-bom and kotlin-bom dependency version imported from external maven BOM provided by kork-bom, as per the gradle documentation https://docs.gradle.org/6.9.1/userguide/platforms.html#sub:bom_import, we can use gradle enforcedPlatform closure as part of the implementation to strictly adhere the versions of direct and transitive dependencies imported BOM. implementation(enforcedPlatform("io.spinnaker.kork:kork-bom:$korkVersion")) * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1519) Co-authored-by: root <root@92ccf252161e> * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1520) Co-authored-by: root <root@8e952337838c> * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1521) Co-authored-by: root <root@e15a7ff336aa> * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1522) Co-authored-by: root <root@00e70a80e3dd> * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1523) Co-authored-by: root <root@4cdab225ba98> * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1524) Co-authored-by: root <root@2bf6cb9b4370> * chore(dependencies): Autobump fiatVersion (spinnaker#1528) Co-authored-by: root <root@69a0efe35201> * chore(ci): GHA - container image and apt package build & push (spinnaker#1529) to Google Artifact Registry see: spinnaker/rosco#841 Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * chore(ci): GHA - simplify build versioning (spinnaker#1530) - collapse version info gathering steps into single `build_variables` step - collapse version info parts into single string and use everywhere. - use short git sha: `(git rev-parse --short HEAD)` Note `build.yml` versioning is not compatible with Debian package building as gradle plugin enforces `^[0-9]+`. We don't publish master branch or release-* branches to GAR apt repository though. Prefixing the version with `<tag>-dev-` or something and publishing Debian packages is possible but may pollute `apt-cache policy spinnaker-rosco` output and overall be unnecessary with regular releases. * fix(plugins-test): try harder for the version of versionNotSupportedPlugin to actually not be supported (spinnaker#1532) Before this, a gate version >= 2.0.0 would cause versionNotSupportedPlugin to get used, causing tests to fail, and making it impossible to e.g. release gate. * chore(cit): GHA - plugin builds require SemVer (spinnaker#1531) I wanted to avoid confusion between a git tag `X` building version `X` and a master or release branch building version `X-dev-*` but it seems unavoidable. SemVer is required by plugins. See constraint: https://github.com/spinnaker/kork/blob/5dc6bb98615667f1b4f3e18445c1651d773c9f6b/kork-plugins/src/main/kotlin/com/netflix/spinnaker/kork/plugins/SpinnakerServiceVersionManager.kt#L47 changes: - fetch full git repository so that we can access previous tag in branch. Convert `release.yml` to this method instead of `run: git.. --unshallow`. - use previous git tag as start of version string. Cut the 'v' prefix from the tag, 'v1.2.3' -> '1.2.3' as required for Plugins (and Debians fwiw): `Caused by: Unexpected character 'LETTER(v)' at position '0', expecting '[DIGIT]'` - append `-dev-<branch_name|'pr'>` to designate that it is not an official version. The short git SHA and date time are NOT present on release versions (eg: 1.2.3) so that also differs. - do this version setting in `pr.yml` as well so we might pick up version issues in PR's and not just at merge. * chore(dependencies): Autobump korkVersion (spinnaker#1536) Co-authored-by: root <root@3f84b148af75> * chore(dependencies): Autobump spinnakerGradleVersion (spinnaker#1537) Co-authored-by: root <root@87e31b5c1a0c> * feat(credentials): Update account type discriminator (spinnaker#1533) This normalizes the type discriminator in account definitions to match that of account credentials instances (i.e., the type of CredentialsDefinition instance and Credentials instance are both specified through the "type" property). This also removes redundant authorization annotations that are better enforced by AccountDefinitionService in Clouddriver. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> * resolved AuthConfig file conflict. Co-authored-by: Calvin Tse <sam.calvin.tse@gmail.com> Co-authored-by: David Byron <dbyron@salesforce.com> Co-authored-by: Emmanouil Katefidis <e.katefidis@outlook.com> Co-authored-by: Justin Field <justin.field@armory.io> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Thomas Swanson <tomswanson4444@gmail.com> Co-authored-by: Cameron Fieber <cfieber@netflix.com> Co-authored-by: spinnakerbot <spinbot@spinnaker.io> Co-authored-by: root <root@265713e22300> Co-authored-by: root <root@ca7e6659c3b3> Co-authored-by: root <root@7e927306ac3d> Co-authored-by: Cristhian Castaneda <ccastanedarivera@gmail.com> Co-authored-by: root <root@01b270ba5f94> Co-authored-by: root <root@73790eeb50df> Co-authored-by: root <root@a229fbda21b3> Co-authored-by: Matt <6519811+mattgogerly@users.noreply.github.com> Co-authored-by: Matt Sicker <boards@gmail.com> Co-authored-by: Cameron Motevasselani <cmotevasselani@gmail.com> Co-authored-by: Cameron Motevasselani <cameron@armory.io> Co-authored-by: Matt Sicker <msicker@apple.com> Co-authored-by: root <root@d38215f0a8da> Co-authored-by: Chris Phillips <4722632+chris-h-phillips@users.noreply.github.com> Co-authored-by: kskewes-sf <96093759+kskewes-sf@users.noreply.github.com> Co-authored-by: Sandesh <sandeshjainhyd@gmail.com> Co-authored-by: root <root@92ccf252161e> Co-authored-by: root <root@8e952337838c> Co-authored-by: root <root@e15a7ff336aa> Co-authored-by: root <root@00e70a80e3dd> Co-authored-by: root <root@4cdab225ba98> Co-authored-by: root <root@2bf6cb9b4370> Co-authored-by: root <root@69a0efe35201> Co-authored-by: David Byron <82477955+dbyron-sf@users.noreply.github.com> Co-authored-by: root <root@3f84b148af75> Co-authored-by: root <root@87e31b5c1a0c>
nhtzr
pushed a commit
to armory/clouddriver
that referenced
this pull request
Aug 18, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (spinnaker#5652) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
apoorvmahajan
pushed a commit
to apoorvmahajan/front50
that referenced
this pull request
Aug 29, 2022
…n of direct and transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (spinnaker#87) Picked from spinnaker@7abbfc0 While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure.
dbyron-sf
added a commit
to dbyron-sf/kayenta
that referenced
this pull request
Aug 29, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure. See also the corresponding orca change: spinnaker/orca#4231 This doesn't fix the current test failure: ./gradlew :kayenta-integration-tests:test --tests GraphiteStandaloneCanaryAnalysisTest but it still feels correct. As far as actual dependency changes, they don't seem super significant, though the guava and groovy changes are solid confirmation for me that this is the way forward. Here's a partial list. There are similar changes for other jackson components. before: org.slf4j:slf4j-api -> 1.7.32 org.yaml:snakeyaml:1.26 -> 1.27 io.micrometer:micrometer-core:1.5.14 -> 1.7.5 com.fasterxml.jackson.core:jackson-databind:2.11.4 -> 2.13.2 junit:junit:4.13.1 -> 4.13.2 com.google.guava:guava:22.0 -> 30.1.1-android org.apache.commons:commons-lang3:3.5 -> 3.11 org.codehaus.groovy:groovy:2.5.14 -> 3.0.6 (c) org.codehaus.groovy:groovy-xml:2.5.14 -> 3.0.6 (c) org.codehaus.groovy:groovy-json:2.5.14 -> 3.0.6 (c) after: slf4j:slf4j-api -> 1.7.30 org.yaml:snakeyaml:1.26 io.micrometer:micrometer-core:1.5.14 com.fasterxml.jackson.core:jackson-databind:2.11.4 -> 2.12.6.1 junit:junit:4.13.1 com.google.guava:guava:22.0 -> 30.0-jre org.apache.commons:commons-lang3:3.5 -> 3.9 org.codehaus.groovy:groovy:2.5.14 (c) org.codehaus.groovy:groovy-xml:2.5.14 (c) org.codehaus.groovy:groovy-json:2.5.14 (c)
dbyron-sf
added a commit
to spinnaker/kayenta
that referenced
this pull request
Aug 30, 2022
…nd transitive dependencies version using kork-bom for upgrading the spring-boot 2.3.x. (#908) While upgrading the spring-boot 2.2.x to 2.3.x, encountered issue of uncontrolled conflict resolution of jackson and kotlin dependencies in gate (spinnaker/gate#1505). In order to avoid any such issue with other components for upgrades to spring-boot 2.3.x as well as for any future spring-boot upgrades, we can introduce strict adherence of imported maven kork-bom by replacing platform to enforcedPlatform closure. See also the corresponding orca change: spinnaker/orca#4231 This doesn't fix the current test failure: ./gradlew :kayenta-integration-tests:test --tests GraphiteStandaloneCanaryAnalysisTest but it still feels correct. As far as actual dependency changes, they don't seem super significant, though the guava and groovy changes are solid confirmation for me that this is the way forward. Here's a partial list. There are similar changes for other jackson components. before: org.slf4j:slf4j-api -> 1.7.32 org.yaml:snakeyaml:1.26 -> 1.27 io.micrometer:micrometer-core:1.5.14 -> 1.7.5 com.fasterxml.jackson.core:jackson-databind:2.11.4 -> 2.13.2 junit:junit:4.13.1 -> 4.13.2 com.google.guava:guava:22.0 -> 30.1.1-android org.apache.commons:commons-lang3:3.5 -> 3.11 org.codehaus.groovy:groovy:2.5.14 -> 3.0.6 (c) org.codehaus.groovy:groovy-xml:2.5.14 -> 3.0.6 (c) org.codehaus.groovy:groovy-json:2.5.14 -> 3.0.6 (c) after: slf4j:slf4j-api -> 1.7.30 org.yaml:snakeyaml:1.26 io.micrometer:micrometer-core:1.5.14 com.fasterxml.jackson.core:jackson-databind:2.11.4 -> 2.12.6.1 junit:junit:4.13.1 com.google.guava:guava:22.0 -> 30.0-jre org.apache.commons:commons-lang3:3.5 -> 3.9 org.codehaus.groovy:groovy:2.5.14 (c) org.codehaus.groovy:groovy-xml:2.5.14 (c) org.codehaus.groovy:groovy-json:2.5.14 (c)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Spring boot has moved to gradle based dependency management from v2.3.x. This change has brought issue of conflict resolution failure of the Jackson-bom version and kotlin-bom version with gate service when it consumes the maven-bom generated by kork. The issue details are available in given link.
https://docs.google.com/document/d/1Ck4KeoB1ER0aQUTnf3e-x-M3i2Ur0It7YaaxEMiMXls/edit
To resolve this issue while upgrading gate service with spring v2.3.x, we must require the spring dependency management gradle plugin.